package com.gitee.liuzhi.demo.other;

/**
 * @Author liuzhi
 * @Date 2023/5/14 14:21
 * @Version 1.0
 * @Description 代码规范文档
 */
public class CodeStandardDemo {

    /*
    1. 添加必要的注释
    1.1 好的方法名, 变量名就是最好的注释
    1.2 方法内部复杂业务逻辑或者算法需要添加注释
     */

    /*
    2. 日志打印规范
    2.1 日志级别不要任意使用info, 常见的日志级别有 error、warn、info、debug
    2.2 日志需要打印调用方法的入参和响应结果
    2.3 日志需要打印关键参数, 如 : userId, corpId, business 等
    2.4 日志打印包含铭感信息, 如手机号、身份证等, 需要脱敏处理
    2.5 不符合预期情况, 如出现了异常, 都需要打印相关的日志
     */

    /*
    3. 命名规范
    3.1 Java代码命名应该清晰、简洁和易于理解
    3.2 类和接口使用大驼峰命名
    3.3 方法和变量使用小驼峰命名
    3.4 常量使用全大写和下划线
     */

    /*
    4. 参数校验
    4.1 参数是否全部做了校验 (如:id 的非空检查,金额的范围检查,name 的长度校验)
    4.2 业务逻辑的处理需要遵循'先检查、后处理'的原则
     */

    /*
    5. 判空处理
    5.1 获取对象属性时, 都要判空处理, 避免 NPE
    5.2 遍历列表时也需要对元素进行判空
     */


    /*
    6. 异常处理规范
    6.1 不要捕获通用的 Exception, 而应该尽可能捕获特定的异常
    6.2 捕获到异常时, 应该打印日志以便于调试
    6.3 使用 finally 释放资源
    6.4 不要使用 e.printStackTrace(), 而是使用 log 打印日志
     */

    /*
    7. 程序逻辑清晰, 主次分明
    7.1 如注册接口中, 可以将参数校验、初始化信息、插入用户记录、结果处理等逻辑抽取为不同的模块方法
     */

    /*
    8. 注意代码坏味道问题
    8.1 大量重复代码 (抽公共方法)
    8.2 方法参数过多 (封装为 DTO 对象)
    8.3 方法过长 (抽取为小函数)
    8.4 判断条件太多 (优化 if...else...)
    8.5 不处理没用的代码 (如没用的 import)
    8.6 避免过度设计
     */

    /*
    9. fail fast 快速失败的代码风格
    9.1 反例: 判断符合条件的逻辑, 然后在 if 嵌套里写逻辑
    9.2 正例: 判断不符合后续条件的逻辑, 尽快 return
     */

}
